home *** CD-ROM | disk | FTP | other *** search
/ Aminet 50 / Aminet 50 (2002)(GTI - Schatztruhe)[!][Aug 2002].iso / Aminet / util / boot / ShellUpdate.lha / Documentation / LoadModule < prev    next >
Text File  |  2001-12-22  |  11KB  |  289 lines

  1. Short:    Install Libs/Devs reset-proof, ROM-Updates replacement
  2. Uploader: thor@math.tu-berlin.de (Thomas Richter)
  3. Author:   thor@math.tu-berlin.de (Thomas Richter)
  4. Type:     util/boot
  5. Version:  40.7
  6. Requires: OS 3.0, 3.5 or 3.9 recommended, possibly MuProtectModules.lha
  7.  
  8. _____________________________________________________________________________
  9.  
  10. Purpose of LoadModule:
  11.  
  12. LoadModule installs so called "resident modules" in a reset-proof way,
  13. possibly replacing ROM modules by disk-based modules, similar to what 
  14. SetPatch and its "ROM-Updates" mechanism does. "Resident modules" are
  15. loadable binaries containing a special structure telling the Os how to 
  16. initialize them and what to perform on initialization - Amiga libraries 
  17. and devices are the canonical example of these modules, the "ram-handler" 
  18. is another.
  19.  
  20. "LoadModule" can be used to install these resident modules in a reset
  21. proof way such that they are available immediately at system bootstrap
  22. time. This is desired whenever a module is required for booting, as
  23. for example some of modules in the Amiga-Os ROM-Updates. "LoadModule"
  24. can therefore be used as a more canonical form of the ROM-Updates since
  25. it does not require an undocumented file format - modules have to be 
  26. provided as loadable disk based binaries in their most canonical form,
  27. and can be kept in their canonical location. For example, the V45 
  28. "console.device" could be kept in DEVS: similar to all other devices.
  29.  
  30. "LoadModule" can be used as well to replace the ROM-based icon and 
  31. workbench.libraries by their disk-based 3.5 and 3.9 replacments, or
  32. to make modules reset-proof that are typically disk-based, for example
  33. the diskfont.library or the mmu.library.
  34.  
  35.  
  36. Features:
  37.  
  38. -    Requires modules as loadable binaries in a canonical and documented
  39.     file format rather than requiring an undocumented file structure.
  40. -    Checksums all modules such that damaged modules will be detected.
  41. -    May place modules in non-MEMF_KICK-able memory using some "arcane
  42.     magic" for boards where no autoconfigurable memory is available,
  43.     provided this memory is reset-persistent. This goes for most A2K
  44.     based GVP accelerators.
  45. -    May or may not cause a reboot and can therefore be bundled with
  46.     Os 3.5/3.9 SetPatch and MuMove4K.
  47. -    Before rebooting, ensures that disk buffers are written out to 
  48.     avoid invalidated disks.
  49. -    Allows listing of the installed resident modules.
  50. -    Can be told to remove itself when required.
  51. -    Can be extended by means of MuProtectModules to optionally
  52.     write protect some ROM modules.
  53. -    It's free! (But check the licence conditions below.)
  54. _____________________________________________________________________________
  55.  
  56. Synopsis:
  57.  
  58. LoadModule    MODULE/M,LIST/S,NOREBOOT/S,IGNOREVERIFY/S,NOMEMFKICK/S,
  59.         REVERSE/S,HEADERFORWARDS/S,REMOVE/S 
  60.  
  61.  
  62. MODULE/M:        Several file names of resident modules to be made
  63.             reset-resident. The file names need not to correspond
  64.             to the names of the resident modules, though.
  65.             "LoadModule" will figure out the correct names itself.
  66.  
  67. LIST/S:            List all resident modules installed by "LoadModule"
  68.  
  69. NOREBOOT/S:        Avoid a reboot even if this would be apropriate. This
  70.             is useful for cascading "LoadModule" with other tools
  71.             that would reboot the machine anyhow, e.g. MuMove4K.
  72.  
  73.             "LoadModule" tries to reboot the machine whenever it
  74.             is invoked for the first time and no resident modules
  75.             are found, or whenever it shall be removed and some
  76.             modules are installed.
  77.  
  78. IGNOREVERIFY:        Ignore invalid or non-validated devices when rebooting.
  79.             Otherwise, LoadModule would abort the reboot process
  80.             printing a warning message.
  81.             This is useful if you must work with a damaged drive
  82.             always returning an error status.
  83.             This will also disable the smart shut-down mechanism
  84.             which would otherwise shut down all filing-system
  85.             devices in a "friendly" way.
  86.  
  87. NOMEMFKICK:        Use MEMF_PUBLIC memory to keep the resident modules.
  88.             Note: This requires some magic *and* reset-persistent
  89.             memory. It should be used *only* in case 
  90.             a) otherwise MEMF_CHIP or 16-bit memory would be used
  91.                and this is not tolerateable 
  92.             *AND*
  93.             b) you really really really know what you're doing.
  94.  
  95. REVERSE:        Allocate resident modules "upside down" moving them
  96.             in the top area of the memory. It is usually a good
  97.             idea to use this option.
  98.  
  99. HEADERFORWARDS:        Allocate the resident part of LoadModule itself in
  100.             non-reverse sense. This resident part will install
  101.             and replace all resident modules by the disk-based
  102.             modules on a reboot and *MUST* go into MEMF_KICK able
  103.             memory (no magic here!). It is by default allocated
  104.             "upside down", but this can be disabled in case it
  105.             conflicts with some programs.
  106.  
  107. REMOVE:            Removes "LoadModule" and its modules from the 
  108.             reset-resident list and causes a reboot, unless 
  109.             NOREBOOT is given. In that case, removal is delayed
  110.             up to the next reboot.
  111. _____________________________________________________________________________
  112.  
  113. Examples:
  114.  
  115. The following one-liner places the Os 3.5/3.9 based icon and workbench
  116. libraries on the reset-resident list replacing the ROM-modules. This
  117. line should go into the startup-sequence *in front of SetPatch* 
  118. (as otherwise SetPatch does this job anyhow by a different approach...)
  119.  
  120. LoadModule LIBS:icon.library LIBS:workbench.library reverse
  121.  
  122.  
  123.  
  124. The following lines show how to bundle LoadModule with MuMove4K as to
  125. avoid a double reboot:
  126.  
  127. LoadModule LIBS:icon.library LIBS:workbench.library reverse noreboot
  128. MuMove4K
  129.  
  130.  
  131. The next example demonstrates how one could replace the ROM-Updates
  132. mechanism of SetPatch provided you would have the modules as separate
  133. files on disk. It also disables NSD.
  134.  
  135. LoadModule LIBS:icon.library LIBS:workbench.library         +
  136.        DEVS:console.device L:Ram-Handler L:FastFileSystem     +
  137.        reverse noreboot
  138. MuMove4K
  139. SetPatch NOROMUPDATES NONSD >NIL:
  140.  
  141.  
  142.  
  143. Finally, the same on a GVP accelerator without automounting 32 bit
  144. memory placing the modules in MEMF_PUBLIC instead:
  145.  
  146. LoadModule LIBS:icon.library LIBS:workbench.library         +
  147.        DEVS:console.device L:Ram-Handler L:FastFileSystem     +
  148.        nomemfkick noreboot
  149. MuMove4K
  150. SetPatch NOROMUPDATES NONSD >NIL:
  151.  
  152.  
  153. List the installed resident modules:
  154.  
  155. LoadModule LIST
  156.  
  157.  
  158. On my system, this presents the following output:
  159.  
  160.  
  161. Resident modules installed:
  162.  
  163. icon.library         icon.library 44.543 (6.6.2000)
  164. workbench.library    workbench.library 45.101 (23.11.2000)
  165. console.device       console 44.6 (31.3.2000)
  166. ram-handler          ram 44.21 (2.9.2000)
  167. filesystem           fs 45.9 (3.9.2000)
  168.  
  169.  
  170.  
  171. NOTE: I leave it to the expert as an "easy exercise" to extract the 
  172. resident modules out of the ROM-Updates file. Don't ask, I won't
  173. provide further information.
  174.  
  175. _____________________________________________________________________________
  176.  
  177. History:
  178.  
  179. LoadModule 40.1:    
  180.  
  181. This is the first release. It was more or less written because I don't
  182. like the ROM-Updates mechanism overly, especially its requirement for an 
  183. undocumented file format - and as favour for Ralph Babel in return for a 
  184. new Guru-ROM and helping me on my SCSI configuration.
  185.  
  186.  
  187. LoadModule 40.5:
  188.  
  189. LoadModule does no longer require 32K alignment for each of its modules,
  190. 32K alignment for the complete set of modules is now enough. However, this
  191. requires release 40.2 of MuProtectModules or higher if module protection 
  192. is desired.
  193.  
  194.  
  195. LoadModule 40.6:
  196.  
  197. Forgot to NULL terminate the resident list which could have caused crashes
  198. on some systems. Fixed the "REMOVE" option which did not work properly.
  199.  
  200.  
  201. LoadModule 40.7:
  202.  
  203. Some format strings of the "LoadModule" failure messages were corrupt. This
  204. has been fixed now.
  205.  
  206. _____________________________________________________________________________
  207.  
  208.                          The THOR-Software Licence (v2, 24th June 1998)
  209.  
  210.  
  211. This License applies to the computer programs known as "LoadModule"
  212. The "Program", below, refers to such program. The "Archive" refers to the 
  213. package of distribution, as prepared by the author of the Program, 
  214. Thomas Richter. Each licensee is addressed as "you".
  215.  
  216.  
  217.  
  218. The Program and the data in the archive are freely distributable
  219. under the restrictions stated below, but are also Copyright (c)
  220. Thomas Richter.
  221.  
  222. Distribution of the Program, the Archive and the data in the Archive by a
  223. commercial organization without written permission from the author to any
  224. third party is prohibited if any payment is made in connection with such
  225. distribution, whether directly (as in payment for a copy of the Program) or
  226. indirectly (as in payment for some service related to the Program, or
  227. payment for some product or service that includes a copy of the Program
  228. "without charge"; these are only examples, and not an exhaustive enumeration
  229. of prohibited activities).
  230.  
  231.  
  232. However, the following methods of distribution
  233. involving payment shall not in and of themselves be a violation of this
  234. restriction:
  235.  
  236.  
  237. (i) Posting the Program on a public access information storage and
  238. retrieval service for which a fee is received for retrieving information
  239. (such as an on-line service), provided that the fee is not
  240. content-dependent (i.e., the fee would be the same for retrieving the same
  241. volume of information consisting of random data).
  242.  
  243.  
  244. (ii) Distributing the Program on a CD-ROM, provided that
  245.  
  246. a) the Archive is reproduced entirely and verbatim on such CD-ROM, including
  247. especially this licence agreement;
  248.  
  249. b) the CD-ROM is made available to the public for a nominal fee only,
  250.  
  251. c) a copy of the CD is made available to the author for free except for
  252. shipment costs, and
  253.  
  254. d) provided further that all information on such CD-ROM is redistributable
  255. for non-commercial purposes without charge.
  256.  
  257.  
  258. Redistribution of a modified version of the Archive, the Program or the
  259. contents of the Archive is prohibited in any way, by any organization,
  260. regardless whether commercial or non-commercial. Everything must be kept
  261. together, in original and unmodified form.
  262.  
  263.  
  264.  
  265.  
  266. Limitations.
  267.  
  268.  
  269. THE PROGRAM IS PROVIDED TO YOU "AS IS", WITHOUT WARRANTY. THERE IS NO
  270. WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
  271. LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  272. PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
  273. RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
  274. THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
  275. SERVICING, REPAIR OR CORRECTION.
  276.  
  277.  
  278. IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE THE PROGRAM, THE ARCHIVE
  279. AND ALL DATA OF THIS ARCHIVE FROM YOUR STORAGE SYSTEM. YOU ACCEPT THIS
  280. LICENCE BY USING OR REDISTRIBUTING THE PROGRAM.
  281.  
  282.  
  283.                                                         Thomas Richter
  284.  
  285. _____________________________________________________________________________
  286.  
  287. Thomas,    
  288.     May 2001
  289.